InfoMagic Internet Tools 1995 April/Internet Tools.iso/dos_win/winsock/hacklist/94-05/text0015.txt

Text File | 1994-05-19 | 7.8 KB | 168 lines

Thus expounded Bob Quinn on May 4,11:50pm:
/--------------------
note: | xxx = Bob
      |> xxx = me

[after an anlysis on why itis not possible to know whether a close
 was gracefully successful or abortive ]

|I always thought that too, but after Bruce's persistence now I
|realize that it's not defined this way (though it should be).
|You get the FD_CLOSE when the socket goes into FIN_WAIT ...which
|is just after you *send* the FIN, not when you recieve it (which
|would be when it enters TIME_WAIT).  Stupid?  Yup.  There's no
|sense asking to be told something you already know.
|
|>          One could argue that the paragraph under WSAAsyncSelect that begins
|>  "The error code in an FD_CLOSE message indicates whether the socket
|>  close was graceful or abortive" would mandate that FD_CLOSE is
|>  NOT posted as soon as the application calls closesocket() or shutdown(),
|>  because the DLL doesn't know yet whether the close will work properly,
|>  and so can't tell yet what error code to post.
|>          In fact, I beleive the semantics you want can be acheived if, in the
|>  bit that says "...FD_CLOSE is posted when the connection goes into the
|>  FIN_WAIT or CLOSE_WAIT states", the "FIN_WAIT" is interpreted as a typo,
|>  and should have been "TIME_WAIT" :-)
|
|Exactamundo.
|
|This sounds like fodder for the ambiguities group (or whatever
|it's called) for WinSock 2.  Boy, won't that be a fun group.

I wouldn't miss it for anything, although I don't think it will be any
more enjoyable than a dentist visit. In this case, though, I don't feel
that there will be too many problems.
    In over an hour of coming up with various scenarios, I can't find
one situation where an application written to the spec as it is interpreted
now will be disadvantaged if the FD_CLOSE is not posted until just slightly
later than some stacks are doing, based on the FIN_WAIT/CLOSE_WAIT
paragraph, which has been taken too literally by most of us - probably
because it mentioned concrete examples of when to do something, so we all
thought it would be easier to beleive it than to think of what the correct
behaviour might be based on a more vague paragraph. If the FD_CLOSE is not
posted until the remote's FIN/ACK arrives, I don't feel that _any_ existing
code will break, so the "FIN_WAIT" can be altered to read "TIME_WAIT" in
everybodies copies of Winsock 1.1 without any drama at all.

    If _anybody_ can think of a code sequence that won't work correctly
under this change, please post it.

    I don't feel very comfortable with the approach, but it could be
argued that, since the other paragraphs and sentences, although a little
more vague, contradict this one, it should never have been interpreted as
correct by right-thinking people in the first place (by a form of logic
known as "majority rules" :^P )

Note that I don't beleive FD_CLOSE should be posted in either FIN_WAIT_1
OR FIN_WAIT_2 - after sending the local FIN, both the remote ends ACK
and FIN should be received before posting FD_CLOSE (which is when the
stack enters TIME_WAIT).

Note 2: I'm sure its not a good idea to be scattering details that may
or may not apply to implementations internally within a spec of this
sort, mandating the internal structure. I don't think talking about
when to post FD_CLOSE in terms of internal states, particularly when they
are specific to TCP/IP, is very smart at all, and the whole
paragraph will have to be re-written to support a more protocol-neutral
approach when WinSock/IPX and WinSock/Appletalk are being discussed.

Again: can anybody else think of any way that an application might break
if I alter our Winsock so that FD_CLOSE is posted when the remote
end's FIN arrives - that is, in CLOSE_WAIT or TIME_WAIT, _not_ FIN_WAIT ?


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Fri May  6 05:15:58 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA16895; Thu, 5 May 1994 20:02:34 -0400
Received: by usage.csd.unsw.OZ.AU id AA17267
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Fri, 6 May 1994 10:02:23 +1000
Received: by atlas (4.1/1.35)
    id AA20074; Fri, 6 May 94 10:16:00 EST
Message-Id: <9405060016.AA20074@atlas>
From: [e-mail]
Date: Fri, 6 May 1994 10:15:58 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail],
        Multiple recipients of list <[e-mail]>
Subject: Re: Curious behaviour from winsock

Thus expounded [e-mail] on May 5,10:05am:
/--------------------
|
|>>  My Conclusion: The quoted portions are 2:1 in favour of posting
|FD_CLOSE
|>>          when the remote'd FIN arrives, NOT when the local app calls
|>>          shutdown/closesocket. Any stack that does not behave so is
|>>          only 33% WinSock compliant w.r.t. FD_CLOSE, and we should be
|>>          as understanding as possible of the confusion.
|>
|Unfortunately, the 33% which that stack agrees with is the most explicit
|reference, and the others could possibly be interpreted in different ways
|to support either side of the argument.

Bruce,
    Sorry, but I'm a bit dozy this morning.

    How can the paragraph starting "The error code in an FD_CLOSE
message ..." and the sentence "This results from the remote end performing
a shutdown() on the send side or a closesocket()." be interpreted as
supporting the premise that FD_CLOSE should be posted in FIN_WAIT - that is,
as soon as the relevent call is made, possibly even before the FIN packet
has gone out onto the wire?

    Inquiring minds, etc...


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Fri May  6 02:35:17 1994
Received: from isi.FrontierTech.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA11541; Fri, 6 May 1994 09:34:44 -0400
Received: from bruces.FrontierTech.COM by isi.FrontierTech.COM (5.65/1.40)
    id AA08817; Fri, 6 May 94 08:32:54 -0500
X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02)
Message-Id: <[e-mail]>
From: [e-mail]
Date: Fri, 06 May 94 08:35:17 CST
Subject: Re: Curious behaviour from winsock
To: Multiple recipients of list <[e-mail]>
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: Text/Plain; Charset=US-ASCII

>       How can the paragraph starting "The error code in an FD_CLOSE
>message ..." and the sentence "This results from the remote end
performing
>a shutdown() on the send side or a closesocket()." be interpreted as
>supporting the premise that FD_CLOSE should be posted in FIN_WAIT - that
is,
>as soon as the relevent call is made, possibly even before the FIN packet
>has gone out onto the wire?
>
When I wrote that, I was thinking someone who really wanted to split hairs
could argue that it doesn't specify that the closesocket occurred on the
remote (you could insert pauses at creative places to imply that the
closesocket could be on either end).  Unfortunately, that would *also*
conflict with the statement that closesocket cancels notifictations!

I have no problem with posting in TIME_WAIT, but I do have a problem with
branding stacks "noncompliant" because they followed an explicit statement
in the spec (a statement which, ironically, was supposed to *reduce*
confusion  : >  ).

****************************************
Bruce A Backman ([e-mail])
Frontier Technologies Corporation
10201 North Port Washington Road
Mequon,  WI  53092
***************************************